Web services networks are rapidly evolving technology architectures allowing applications to tap into a variety of services in an extremely efficient and cost effective manner. Web services enable cost-effective and efficient collaboration among entities within an enterprise or across enterprises. Web or application services are network addressable computing resources that exchange data and execute processes. Essentially, Web services are applications exposed as services over a computer network and employed by other applications using Internet standard technologies, such as XML, SOAP, WSDL, etc. Accordingly, Web applications can be quickly and efficiently assembled with services available within an enterprise LAN or external services available over open computer networks, such as the Internet.
A Web services network can be deployed across an enterprise LAN or across a Wide Area Network, such as the Internet. A typical Web services network includes at least one network services broker or gateway that is operative to receive a service request and route the service request to the appropriate resource. A broker is a specially configured server or cluster of servers acting as an intermediary for Web service requests and responses. As Web services network usage increases, however, the broker can become a bottleneck. To ease this bottleneck, the prior art solution is simply to add additional processing power to the broker (e.g., additional servers), which is costly, inefficient, and fails to leverage the enterprise's investments in its existing network infrastructure. Moreover, the centralized nature of the broker creates reliability concerns in that failure of the broker disables the applications accessing services through it. Accordingly, U.S. application Ser. No. 09/990,722 discloses a distributed Web services network architecture that, among other things, alleviates the bottleneck and point-of-failure concerns discussed above.
As the use of Web services network architectures expands, the complexity of the processes that utilize Web- or application-services increases as well. For example, various stateful messaging protocols have been developed to support complex or coordinated interactions between various endpoints in a web services network. For example, SOAP Conversation (SOAP-Conversation) is a SOAP- and WSDL-based specification that defines long-running and asynchronous interactions between SOAP-based senders and receivers. A SOAP-Conversation is expressed as a SOAP header entry within a SOAP envelope. In addition, WS-ReliablingMessaging is another SOAP and WSDL based specification that provides delivery assurances that a given message reached its ultimate destination. WS-Coordination and WS-Transaction are further examples of other SOAP- and WSDL-based protocols that introduce elements of statefulness. A fundamental requirement introduced by stateful protocols is that, once an endpoint initializes stateful data (such as a session, context, or conversation token) in response to a Web service invocation, then all subsequent messages referencing or requiring that stateful data must be routed to that same endpoint.
While, in theory (or at least where only a single endpoint supports a given web service), adherence to this requirement appears to be somewhat straightforward, complying with this requirement becomes quite complex where the web services network environments comprises multiple control points, and the given web- or application-service is supported by multiple endpoints. Specifically, as discussed in U.S. application Ser. No. 09/990,722, a consuming application invokes a given web service by composing a request identifying a service operation and transmitting it to a control point. The control point accesses a routing table or web services network directory to, among other things, identify and select an endpoint location (often from a plurality of possible endpoint locations). The request is then forwarded to the selected endpoint. Problems can arise, however, when the consuming application transmits subsequent messages associated with an existing conversation to another control point, which has no state or other information concerning the existing conversation between the consuming application and the selected endpoint. Specifically, without any coordination mechanism, the message may be forwarded to an endpoint that is not involved in the existing conversation.
In light of the foregoing, a need in the art exists for methods, apparatuses and systems facilitating the support of stateful messaging protocols in web services and other network environments comprising a plurality of distributed control points or routing nodes. Embodiments of the present invention substantially fulfill this need.